home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19970104-19970326
/
000164_news@columbia.edu _Sat Feb 1 00:37:44 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
3KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id AAA12834
for <kermit.misc@watsun.cc.columbia.edu>; Sat, 1 Feb 1997 00:37:44 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id AAA17078
for kermit.misc@watsun; Sat, 1 Feb 1997 00:37:42 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!jaltman
From: jaltman@watsun.cc.columbia.edu (Jeffrey Altman)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: K95 xfer works when FTP doesn't?????
Date: 1 Feb 1997 05:37:38 GMT
Organization: Columbia University
Lines: 34
Message-ID: <5cukr2$14t$1@apakabar.cc.columbia.edu>
References: <32f2266f.55500445@199.1.22.49>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:6514
In article <32f2266f.55500445@199.1.22.49>,
Vincent Fatica <vefatica@syr.edu> wrote:
: Is there some profound difference between sending files via FTP vs.
: via Kermit/TCPIP?
:
: Here's what's happening: On a PPP connection with a provider called
: servtech, whenever I try to upload via FTP from home to a site outside
:
: servtech.com, it bogs right down to almost nothing (<100 cps). But I
: can Kermit (via TCP/IP) the same file to the same host, on the same
: connection, at the expected 3000 cps. I don't get it. Kermit is just
: sending out TCPIP packets just like (?) FTP, isn't it? What might
: account for FTP being horribly slow when Kermit is working normally?
:
: Also, I have been playing with a HTML server on my NT machine. It
: behaves like FTP when trying to send something out onto the internet
: ... god-awful slow.
This is only a guess, but it sounds like someone's TCP/IP implementation
of TCP flow control is bad. FTP/HTTP send files by opening a socket and
sending data without any data being sent back in response. Therefore,
when the TCP window fills and data gets stopped, the restart signal is
not getting through or not getting sent.
Kermit transfers continuously send data in both directions. Therefore,
the available window size is always being piggy backed on top of real
data packets.
Sounds like someone is trashing TCP packets with 0 data.
Jeffrey Altman * Kermit Development Group * Columbia University
* 612 West 115th St #716 * New York, NY * 10025 * (212) 854-1344
C-Kermit 5A(191) for OS/2: http://www.columbia.edu/kermit/cko191.html
Kermit 95 for Windows 95/NT: http://www.columbia.edu/kermit/k95.html